An embedded system is some combination of computer hardware and software, either fixed in capability or programmable, that is specifically designed for a particular kind of application device. Industrial machines, automobiles, medical equipment, cameras, household appliances, airplanes, vending machines, and toys (as well as the more obvious cellular phones and PDA) are among the myriad of possible hosts of an embedded system. Embedded systems that are programmable are provided with a programming interface.
With reference to FIG. 1, a prior art embedded computer system cycling through a series of states is shown. In common storage systems, a RAID (redundant array of independent disks) controller is an embedded computer system 10 that cycles though a series of states 12-20 before the RAID system is fully operational. During the initialization of the RAID application the controller can determine that some serious fault condition exists and lock down as shown at blocks 22-26. Failure states 22-26 can be used to prevent system 10 from encountering a fault during normal operation that could result in data corruption or data loss by implementing a lock down. However, when a controller locks down the storage management software cannot communicate with the controller because the communication protocol used with the storage management software is implemented by the RAID application that was halted in the initialization sequence.
A similar situation can occur when a controller runs a diagnostic application. (Note that some diagnostics are run after the operating system is loaded, but before the main RAID application is loaded.) A controller (e.g., an embedded computer system) can lock down due to a diagnostic failure, again leaving the user with no management interface to assist in diagnosing and repairing the problem. When a controller locks down in the scenarios described above, the user must connect an RS-232 (recommended standard-232) cable to the serial port and use low-level commands (e.g., such as operating system commands similar to DOS and UNIX) to communicate with the controller.
The disadvantage is that the user is given very little help resolving failure scenarios and without help the user could make the same failures (e.g., using incompatible hardware) or make a situation worse (e.g., remove the wrong device). Further, connecting extra cables takes time in the diagnostic process and the cables may not be standard RS-232 cables, so the user may not even have easy access to the interface.
Therefore, it would be desirable to provide a management interface able to assist in diagnosing and repairing a problem with an embedded device.